使用者提出的功能，真的能解決他的困難嗎？

假設我們維護一套接單系統。使用者送出訂單後，系統會呼叫庫存服務扣減可售數量，再更新訂單狀態。某天，營運人員提出需求：「可以在後台加一個『重新處理』的按鈕嗎？」

BA整理的規格很清楚：處理狀態為「失敗」的訂單，營運人員可以按下按鈕，重新呼叫庫存服務；成功後更新訂單狀態，並留下操作紀錄。

從開發角度看，這件事似乎不難：畫面加上按鈕，後端提供API，再讓指定的訂單重新走一次庫存處理流程。按下去能執行，狀態也會更新，任務看起來就完成了。

使用者說的是功能，背後藏著的是問題

接手實作時，我會先看規格的背景說明，確認營運人員在什麼情況下需要按這個按鈕。背景寫的是：有些訂單呼叫庫存服務時發生逾時，營運人員無法自行查明結果，只能找工程師看Log、核對庫存紀錄，再決定要不要補送。他提出按鈕，是希望下次遇到同樣的狀況，不用每次都等工程師。

對照現有程式，會發現一個從規格看不出來的細節：逾時發生時，後台可能一直停在「處理中」，也可能直接記成「失敗」。但庫存服務也許已經扣減了可售數量，只是結果沒有傳回來。也就是說，現有的「失敗」裡，混著「確定沒扣」與「不知道有沒有扣」兩種訂單。

知道這段背景，原本看似單純的需求就多了幾個問題：

• 哪些訂單可以重新處理？如果庫存其實已經扣減，再執行一次會不會重複扣掉數量？
• 按完之後，營運人員怎麼知道庫存處理與訂單狀態都正確了？

這些問題要在實作前帶回團隊確認，再把結果補進文件。假如沒有釐清，按鈕上線後，他可能還是得問工程師：「這筆可以按嗎？」或「我按過了，庫存到底扣了幾次？」

按鈕做出來了，等待工程師的流程卻還在。

知道目的，才有辦法做取捨

問清楚情境之後，我們才有依據討論要做到哪裡。也許需要補上更清楚的處理狀態；也許重送前得先確認下游的結果；也可能現有機制已經足夠，只缺一個讓營運人員操作的入口。

這不代表每次多問一句，都要把小需求做成大變動。如果異常一個月只發生一次，人工確認也很快，先提供有限制的操作方式，可能就能改善流程。但如果每天都有大量訂單卡住，單靠一個按鈕，恐怕只是把工程師的補救工作轉交給營運人員。

理解目的，能幫團隊判斷現在必須處理什麼、哪些可以留到後面。驗收時也不只確認「按鈕能不能重新送出訂單」，還要看看營運人員能否判斷何時可以操作，並知道操作後的結果。

AI寫得越快，越要先弄清楚方向

把規格、現有流程與程式碼提供給AI，它可以一起分析例外、討論做法，再協助實作和測試，也可能先指出「失敗」裡混了兩種情況。但若團隊始終只把目標定在「新增重新處理功能」，產出的程式即使符合規格，也無法證明營運人員原本的困難已經解決。

所以接到需求時，我想先試著說清楚：誰在什麼情境下遇到什麼困難？這個功能預期讓什麼事情變得更好？

在這個例子裡，答案可能是：「營運人員遇到訂單傳送異常時，無法確認結果，只能等工程師協助；我們希望讓他能判斷目前狀態，並在允許的情況下自行恢復處理。」

如果這句話還說不清楚，就先找相關的人補上背景。後面的設計、取捨和驗收，才有一個共同的依據。

程式寫對了，是交付的基本要求。至於問題有沒有解決，還是得回到使用者實際工作的地方看。

「業務說報表產太慢，要求在後台加一個『匯出完成簡訊通知』。」
「加了之後有解決他的問題嗎？」
「沒有，問了才知道他只是要確認今天有幾筆訂單，結果我們讓他等了半小時匯出三萬筆明細。」